It is known that programs written in the JAVA programming language (JAVA is a trademark of Sun Microsystems Inc) are generally run in a virtual machine environment, rather than directly on hardware. Thus a JAVA program is typically compiled into byte-code form, and then interpreted by a JAVA virtual machine (JVM) into hardware command for the platform on which the JVM is executing. The JVM itself is an application running on the underlying operating system. An important advantage of this approach is that JAVA applications can run on a very wide range of platforms, providing of course that a JVM is available for each platform.
JAVA is an object-oriented language. Thus a JAVA program is formed from a set of class files having methods that represent sequences of instructions (somewhat akin to subroutines). A hierarchy of classes can be defined, with each class inheriting properties (including methods) from those classes which are above it in the hierarchy. For any given class in the hierarchy, its descendants (i.e. below it) are called subclasses, whilst its ancestors (i.e. above it) are called superclasses.
At run-time classes are loaded into the JVM by one or more class loaders, which themselves are organized into a hierarchy. In JAVA, classes are loaded into the JVM's local memory at application runtime, typically in accordance with a ‘classpath’. The classpath defines a search order of locations (directories or JAR—JAVA archive—files) from which classes can be loaded, and a class located at a location earlier in the classpath is loaded before a class located at a location later in the classpath. Once loaded, a class is used from the JVM's local memory rather than reloading for each reference. A JVM can also execute with a shared class cache (i.e., a cache storing classes shared between the JVMs), in which case the classes are loaded into the shared class cache and shared between multiple JVMs. This reduces duplication of read-only data stored in local memory. Objects can then be created as instantiations of these class files. One JAVA object can call a method in another JAVA object. In recent years JAVA has become very popular, and is described in many books, for example “Exploring Java” by Niemeyer and Peck, O'Reilly & Associates, 1996, USA, and “The Java Virtual Machine Specification” by Lindholm and Yellin, Addison-Wedley, 1997, USA.
Multiple JVMs can execute with a shared class cache—that is a cache storing classes shared between the JVMs. Where one or more JVMs are sharing Java classes in a shared memory area (shared cache), if any classloader from any JVM is allowed to store and find classes in the cache, then a system of classpath validation/matching must be employed (when a classloader loads classes from disk, it will try to load the class from each entry in its classpath until it finds the class it is looking for). When a classloader tries to load a class from the shared cache, it is typically quicker to first find the class/classes by name and then determine if the path from which they were originally loaded is valid for the classpath of the caller classloader. This is resource intensive at runtime.
Known implementations of similar systems circumvent this issue in various ways. One known way is to have a shared memory area for each classloader, which then places restrictions on sharing (only another JVM with the same classloader with the same classpath can share the classes). Another known way is that of the Class Data Sharing (CDS) system of Sun Microsystems, Inc., which is based on a read-only file which contains all system classes and cannot be updated.
U.S. patent publication 2004/0039926 discloses the use of hash values to identify modified Java class files, but does not address the matching problem discussed above.
A need therefore exists for system and method for fast matching of classpaths in a shared classes system wherein the above mentioned disadvantage(s) may be alleviated.